Hey @kkharbas ! I don't think we need to have a

dense_vector + field

so we operate on each dense_vector field over each scalar field on the other column, but:

dense_vector + scalar constant

so we use the same scalar constant to operate on every dense_vector field row.

So, we could do something like:

EVAL my_negated_vectors = my_vector_field * -1

or

EVAL my_added_vectors = my_vector_field + 3.0

Right now I don't see the use case for operating on a row by row basis for scalars - and I think in any case using a single scalar constant would be a more frequent use case, and simpler to implement for now.

We may come back to this implementation, but I think for now we should reduce the scope and look for single numeric constants to be applied.

What do you think?

That makes total sense. I was just focussing on completeness of the operations but usability wise its fair to only support scalar constant.

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel

I have a question on the approach - instead of dealing separately with scalar operands in a separate class, convert them via an ExpressionEvaluator to dense vectors so we can operate on them with the current infra.

I had given this approach some consideration but ran into hiccups.
One is we throw error when vector dimensions don't match. Would it be possible to distinguish between the case when an operand is a scalar converted to vector or a vector with dimension == 1?

I will take a fresh look again at this approach.

I have a question on the approach - instead of dealing separately with scalar operands in a separate class, convert them via an ExpressionEvaluator to dense vectors so we can operate on them with the current infra.

I had given this approach some consideration but ran into hiccups. One is we throw error when vector dimensions don't match. Would it be possible to distinguish between the case when an operand is a scalar converted to vector or a vector with dimension == 1?

I will take a fresh look again at this approach.

I tried out this approach of using existing conversion evaluators, e.g. ToDenseVectorFromIntEvaluator, its a neat way to use existing dense_vector support.

Few thoughts and questions on this,

1. Evaluation logic is slightly different for when both arguments are dense_vectors vs one is scalar, e.g. validating dimensions and getting N vs 1 values from the block. The execution path to take depends on the expression and can be injected into the evaluator as isLhsScalar and isRhsScalar boolean parameters. Question/concern is - is it a significant performance concern doing these checks during evaluation (once per page)?
2. This approach can be applied to scalar fields too (not just constants) without adding much complexity. If the concern was just related to complexity, does it make sense to support non-literals?

Pinging @elastic/es-search-relevance (Team:Search Relevance)

test this please

Hi @kkharbas, I've created a changelog YAML for you.